DoH(DNS over HTTPS)

도메인 네임 시스템은 인터넷의 전화번호부 역할을 하며, 사람이 읽을 수 있는 도메인 이름을 컴퓨터가 이해하는 IP 주소로 변환한다. 그러나 기존 DNS는 설계 당시 보안을 고려하지 않아 여러 한계와 취약점을 노출한다.

가장 큰 문제는 평문 통신이다. DNS 쿼리와 응답은 기본적으로 암호화되지 않은 UDP 또는 TCP 패킷으로 전송된다. 이는 네트워크 경로상의 공격자가 패킷을 쉽게 가로챌 수 있음을 의미한다. 이를 통해 공격자는 사용자가 방문하려는 웹사이트를 확인하거나, 응답을 조작하여 사용자를 악성 사이트로 유도하는 DNS 스푸핑 공격을 수행할 수 있다. 또한, 중간자 공격에 취약하여 통신을 감시하거나 변조당할 위험이 상존한다.

다른 한계는 데이터 무결성과 프라이버시 부재이다. 응답의 진위를 확인할 수 있는 메커니즘이 없어, 조작된 응답을 구별하기 어렵다. 더불어, 모든 쿼리는 인터넷 서비스 제공자를 포함한 네트워크 관리자에게 노출된다. 이는 사용자의 방문 기록, 관심사, 행동 패턴을 추적하는 데 악용될 가능성이 있다. 일부 국가나 조직에서는 이 특성을 이용해 특정 도메인에 대한 쿼리를 차단하는 DNS 차단을 수행하기도 한다.

이러한 보안 결함은 HTTPS가 보편화된 현대 인터넷 환경에서 DNS가 취약한 고리가 되게 하였다. DoH는 이러한 기존 DNS의 근본적인 문제를 해결하기 위해 등장한 기술이다.

DoH는 기존 DNS 쿼리가 평문 UDP 또는 TCP 패킷으로 전송되는 방식을, HTTPS 프로토콜 위에서 암호화된 HTTP/2 또는 HTTP/3 세션을 통해 전송하는 방식으로 대체한다. 이는 TLS 암호화를 핵심 메커니즘으로 사용한다. 클라이언트(예: 웹 브라우저)는 DoH 리졸버와 먼저 표준 TLS 핸드셰이크를 수행하여 암호화된 연결을 수립한다. 이 과정에서 서버 인증서를 검증하여 통신 상대방의 신원을 확인하고, 대칭 암호화 키를 협상한다. 이후의 모든 DNS 메시지는 이 암호화 터널 안에서 HTTP POST 또는 GET 요청의 본문으로 캡슐화되어 전송된다.

암호화는 두 가지 주요 보안 목표를 제공한다. 첫째는 기밀성으로, 쿼리 내용(예: 방문하려는 웹사이트의 도메인 이름)과 응답 내용(예: 해당 도메인의 IP 주소)이 네트워크 경로상의 제3자에게 노출되는 것을 방지한다. 둘째는 무결성과 인증으로, 중간자 공격을 통한 쿼리 변조나 가짜 응답을 스푸핑하는 것을 방지한다. 공격자가 암호화된 패킷을 가로채더라도 내용을 읽거나 합법적인 것처럼 변조할 수 없다.

DoH 메시지는 일반적인 HTTPS 트래픽과 구별하기 어렵게 설계되었다. DNS 쿼리와 응답은 HTTP 헤더로 둘러싸여 전송되며, 표준 HTTPS 포트인 443번 포트를 사용한다. 이는 네트워크 관리자가 포트 번호(예: 기존 DNS의 53번 포트)를 기준으로 DNS 트래픽을 식별하고 차단하는 것을 어렵게 만든다. 다음은 DoH 요청과 응답의 기본적인 구조를 보여준다.

이 구조는 DNS 시스템의 기본 기능과 데이터 형식은 유지한 채, 오직 전송 경로만을 암호화한다는 점이 특징이다. 최종적으로 DoH 리졸버는 암호화된 연결에서 DNS 메시지를 추출하여, 자신이 일반적인 재귀적 DNS 쿼리 리졸버로서 수행하는 것과 동일한 과정으로 질의를 처리하고, 결과를 다시 암호화하여 클라이언트에게 되돌려준다.

DoH 클라이언트(예: 웹 브라우저)와 DoH 리졸버 간의 통신은 표준 HTTPS 연결을 통해 이루어진다. 이 과정은 일반적인 HTTPS 핸드셰이크로 시작하여, 암호화된 터널 안에서 DNS 쿼리와 응답이 교환된다.

핸드셰이크 단계에서는 클라이언트가 미리 알고 있거나 구성된 DoH 리졸버의 URL(예: https://dns.example.com/dns-query)에 TCP 연결을 수립한다. 이후 TLS 핸드셰이크를 수행하여 암호화된 보안 채널을 설정한다. 이때 리졸버의 신원은 X.509 디지털 인증서를 통해 검증된다. 연결이 설정되면, 모든 DNS 트래픽은 이 암호화된 터널을 통해 전송되며 외부 관찰자에게는 일반적인 HTTPS 트래픽으로 보인다.

실제 DNS 쿼리와 응답은 HTTP 프로토콜을 통해 전달된다. 클라이언트는 DNS 메시지를 그대로 HTTP 요청의 본문에 담아 application/dns-message 콘텐츠 타입으로 POST 요청을 보내거나, Base64로 인코딩하여 URL 매개변수에 포함시킨 GET 요청을 보낸다. 리졸버는 쿼리를 처리한 후, 마찬가지로 암호화된 HTTP 응답 본문에 DNS 응답 메시지를 담아 클라이언트에게 돌려준다. 전체 과정은 다음 표와 같이 요약할 수 있다.

이 방식은 DNS 트래픽을 다른 모든 HTTPS 웹 트래픽과 구별하기 어렵게 만들어 평문 DNS의 가장 큰 취약점 중 하나였던 도청 및 변조를 방지한다. 또한, HTTP/2 또는 HTTP/3을 지원하면 여러 쿼리를 병렬로 처리하는 등 성능 최적화의 이점도 얻을 수 있다.

DoH는 사용자의 DNS 쿼리 내용을 암호화함으로써, 기존 평문 DNS가 노출시켰던 여러 프라이버시 위협을 완화한다. 가장 직접적인 보호는 사용자가 방문하는 웹사이트의 도메인 이름이 네트워크 상에서 가로채거나 관찰되는 것을 방지하는 것이다. ISP나 공공 와이파이 제공자, 또는 동일 로컬 네트워크에 있는 다른 사용자는 사용자의 암호화된 DNS 트래픽을 통해 특정 웹사이트 방문 기록을 식별할 수 없다.

이 암호화는 사용자의 검색 이력 프로파일링과 이를 기반으로 한 타겟 광고를 어렵게 만든다. 기존에는 DNS 쿼리 로그를 수집하여 사용자의 관심사나 행동 패턴을 분석하는 것이 가능했다. 또한, DNS 스푸핑이나 DNS 캐시 포이즈닝과 같은 공격을 통한 악성 사이트로의 리다이렉션 위험도 줄인다. 이를 통해 사용자는 의도한 정당한 사이트에 더 안전하게 접속할 수 있다.

그러나 프라이버시 보호의 정도는 선택한 DoH 리졸버의 신뢰성에 크게 의존한다. 모든 DNS 쿼리가 해당 리졸버로 집중되므로, 리졸버 공급자가 사용자의 전체 질의 이력을 수집할 가능성이 있다. 이는 프라이버시 위협의 주체가 네트워크 중간자에서 리졸버 공급자로 옮겨갈 수 있음을 의미한다. 따라서 신뢰할 수 없는 리졸버를 사용할 경우 오히려 프라이버시가 침해될 수 있다.

DoH는 HTTPS 프로토콜을 사용하여 DNS 쿼리와 응답을 암호화함으로써 데이터의 무결성을 보장하고 중간자 공격을 효과적으로 방지한다. 기존의 평문 DNS는 전송 과정에서 패킷이 변조될 가능성이 있었지만, DoH는 TLS 암호화를 통해 이를 근본적으로 차단한다.

데이터 무결성은 암호화와 디지털 서명을 통해 유지된다. DoH 리졸버로 전송되는 쿼리와 그에 대한 응답은 종단 간 암호화되어 제3자가 내용을 확인하거나 임의로 변경할 수 없다. 이는 악의적인 공격자가 사용자를 가짜 웹사이트로 유도하는 DNS 스푸핑 공격이나 캐시 중독 공격을 방어하는 핵심 메커니즘이다.

중간자 공격 방지 측면에서 DoH는 다음과 같은 보안성을 제공한다.

따라서 DoH는 사용자가 의도한 DNS 리졸버와의 안전한 통신 채널을 구축하여, 네트워크 상의 어떠한 중간 노드도 DNS 트래픽을 조작하거나 엿들을 수 없게 만든다. 이는 공용 Wi-Fi와 같이 신뢰할 수 없는 네트워크 환경에서 특히 중요한 보안 향상을 가져온다.

DoH는 DNS 쿼리와 응답을 암호화함으로써, 네트워크 중간에서 이루어지는 검열이나 DNS 차단을 우회하는 데 효과적인 수단이 될 수 있다. 기존의 평문 DNS는 네트워크 관리자나 ISP가 특정 도메인에 대한 질의를 감시하고, 해당 질의를 가로채거나 조작하여 접근을 차단하기 쉽다. 그러나 DoH는 모든 DNS 트래픽이 일반적인 HTTPS 트래픽과 구분되지 않는 암호화된 채널을 통해 전송되도록 하여, 이러한 감시와 필터링을 어렵게 만든다.

이 기술의 적용은 국가 차원의 인터넷 검열을 우회하려는 사용자나 특정 웹사이트에 대한 접근 제한이 있는 지역의 사용자에게 유용하다. 예를 들어, 정부가 특정 도메인 네임을 DNS 차단 목록에 등록해 접근을 막는 경우, 사용자가 DoH 리졸버를 사용하면 해당 차단 목록을 적용하지 않는 외부 리졸버로 암호화된 쿼리를 직접 보낼 수 있다. 결과적으로 사용자는 차단된 사이트의 실제 IP 주소를 얻어 접속할 수 있게 된다.

그러나 이 기능은 논란을 일으키기도 한다. 기업 네트워크 관리자나 학교, 국가 보안 기관은 악성 사이트 차단, 적절한 콘텐츠 필터링, 또는 사이버 위협 탐지를 위해 DNS 트래픽 모니터링이 필요할 수 있다. DoH의 광범위한 채용은 이러한 합법적인 네트워크 정책과 보안 조치를 무력화할 가능성이 있다. 사용자가 회사 네트워크에서도 외부 DoH 서비스를 사용하면, 내부 보안 시스템은 사용자가 접속하려는 사이트의 도메인 이름을 알 수 없게 되어 정책 적용이 어려워진다.

따라서 DoH의 검열 우회 기능은 사용자의 디지털 권리와 표현의 자유를 강화하는 동시에, 기존의 네트워크 관리 및 공공 안전 모델과 충돌하는 양면성을 지닌다. 이로 인해 DoH의 기본 설정과 사용에 관한 기술적, 정책적 논의가 지속되고 있다.

DoH(DNS over HTTPS)의 공식 표준은 IETF(인터넷 엔지니어링 태스크 포스)에서 발표한 RFC 8484이다. 이 문서의 제목은 "DNS Queries over HTTPS (DoH)"이며, 2018년 10월에 공식적으로 표준 트랙(Standards Track)으로 출판되었다. RFC 8484은 DoH 클라이언트와 리졸버가 HTTPS를 사용하여 DNS 메시지를 안전하게 교환하기 위한 상호 운용 가능한 방법을 정의한다.

표준은 DoH 트래픽이 반드시 표준 HTTPS 포트인 443번 포트를 사용해야 한다고 명시한다. 이를 통해 DoH 트래픽은 일반적인 웹 트래픽과 구별하기 어렵게 만들어, 감시 및 차단을 회피하는 데 도움을 준다. 쿼리와 응답은 HTTP/2 또는 HTTP/3을 지원하는 HTTPS 연결을 통해 전송되며, DNS 메시지는 "application/dns-message"라는 미디어 타입을 가진 HTTP 페이로드에 담겨 교환된다. 표준은 주로 두 가지 요청 방식을 정의한다: GET 메서드를 사용하며 쿼리를 Base64로 인코딩한 URL 파라미터로 전달하는 방식과, POST 메서드를 사용하여 DNS 메시지를 HTTP 메시지 본문에 직접 담는 방식이다. 일반적으로 POST 방식이 더 널리 사용된다.

RFC 8484은 보안과 프라이버시를 핵심 목표로 삼는다. 표준은 반드시 TLS 1.3 또는 그 이상의 버전을 사용할 것을 권장하며, 이를 통해 통신의 기밀성과 무결성을 보장한다. 또한, 표준은 클라이언트가 HTTP/2의 서버 푸시와 같은 특정 기능에 의존하지 않도록 하여 광범위한 구현과 호환성을 가능하게 한다. 다음 표는 RFC 8484에서 정의한 주요 구성 요소를 요약한다.

이 표준의 확정은 DoH의 상호 운용성과 광범위한 채택의 기반을 마련했다. 주요 웹 브라우저 개발사와 CDN 업체들은 이 RFC를 준수하여 자사의 DoH 서비스와 클라이언트 기능을 구현했다. RFC 8484은 DoH가 기존 DNS 인프라와는 별개로, 웹의 보안 프로토콜 체계 내에서 동작하는 새로운 표준임을 공식화한 문서이다.

DoH를 사용하기 위해서는 클라이언트(예: 웹 브라우저, 운영체제)가 DoH를 지원하는 리졸버의 주소를 알고 있어야 한다. 설정은 일반적으로 수동과 자동 두 가지 방식으로 이루어진다.

수동 설정에서는 사용자가 선호하는 DoH 공급자의 특정 URL을 직접 입력한다. 대표적인 공급자 URL은 다음과 같다.

자동 설정은 DoH를 지원하는 클라이언트 소프트웨어가 내장된 목록에서 사용 가능한 서버를 탐지하거나, ISP가 제공하는 CNAME 기록을 통해 적절한 DoH 서버를 자동으로 찾는 방식이다. 예를 들어, 일부 브라우저는 네트워크의 기본 DNS 서버가 DoH를 지원하는지 확인하고, 지원한다면 자동으로 전환할 수 있다.

운영체제 수준에서의 설정은 플랫폼마다 다르다. Windows 10/11은 네트워크 설정 내에서 DoH 서버 주소를 지정할 수 있다. 맥OS와 리눅스 배포판에서는 일반적으로 네트워크 관리자 도구를 통해 설정하거나, systemd-resolved와 같은 서비스의 구성 파일을 직접 편집하여 DoH 리졸버를 지정한다[1]. 모바일 운영체제인 안드로이드와 iOS 또한 개별 앱 설정 또는 기기의 VPN 및 개인 정보 보호 설정 메뉴를 통해 DoH를 활성화할 수 있다.

DoH 서비스를 제공하는 주요 공급자들은 사용자에게 암호화된 DNS 해석 기능을 제공하며, 공개적으로 이용 가능한 리졸버를 운영한다. 이들은 일반적으로 높은 가용성과 빠른 응답 속도를 보장하기 위해 전 세계에 분산된 서버 인프라를 구축한다. 대표적인 공급자로는 Cloudflare와 Google이 있으며, 이 외에도 Quad9, OpenDNS 등이 있다.

각 공급자는 특정 IP 주소를 통해 서비스를 제공하며, 사용자는 클라이언트 소프트웨어에 이 주소를 설정하여 이용한다. 주요 공급자들의 기본 서버 주소는 다음과 같다.

이들 공급자의 선택은 DNS 쿼리 처리 속도, 로깅 정책, 추가 필터링 기능, 그리고 사용자에 대한 신뢰도에 따라 달라진다. 예를 들어, Cloudflare는 사용자 데이터를 24시간 이상 보관하지 않는다고 공표하는 반면, 일부 공급자는 진단 및 서비스 개선을 위한 로깅을 수행할 수 있다[2]. 따라서 사용자는 자신의 프라이버시 요구사항과 공급자의 정책을 신중히 비교하여 선택해야 한다.

또한, Mozilla나 Apple과 같은 소프트웨어 벤더는 자사 제품에 특정 공급자를 기본값으로 설정하기도 한다. 이는 DoH의 대중화에 기여했지만, 인터넷 트래픽의 중앙화와 특정 기업에 대한 의존도 증가라는 논란을 불러일으키기도 했다. 일부 사용자는 이를 피하기 위해 자체적으로 운영하거나 신뢰하는 소규모 DoH 리졸버를 설정하기도 한다.

DoH는 DNS 트래픽을 암호화하여 프라이버시를 강화하지만, 이 과정에서 기존의 분산된 DNS 인프라 구조가 변화할 수 있다는 점이 지적된다. 전통적인 DNS는 사용자가 설정한 로컬 ISP의 리졸버나 공공 재귀 DNS 서버를 주로 사용하는 반면, DoH는 주로 대형 클라우드 사업자나 콘텐츠 전송 네트워크 업체가 운영하는 몇 개의 주요 공급자에 트래픽이 집중되는 경향이 있다. 이로 인해 DNS 쿼리 처리의 권한과 데이터가 소수의 대형 업체로 중앙화될 위험이 제기된다.

이러한 중앙화는 새로운 신뢰 모델을 요구한다. 사용자는 더 이상 지역 ISP가 아닌, Cloudflare나 Google 같은 글로벌 DoH 공급자를 신뢰해야 한다. 이 공급자들은 암호화된 채널을 통해 모든 DNS 질의와 응답을 처리하게 되므로, 사용자의 전체 도메인 이름 검색 이력에 접근할 수 있는 위치에 서게 된다. 이는 한편으로는 지역 ISP의 데이터 수집으로부터 사용자를 보호할 수 있지만, 다른 한편으로는 방대한 인터넷 사용 데이터가 몇몇 기업에 집중될 수 있음을 의미한다.

중앙화된 신뢰 문제는 네트워크 관리와 자율성 측면에서도 영향을 미친다. 기업이나 교육 기관, 정부 기관은 자체 네트워크 정책을 시행하기 위해 내부 DNS 필터링이나 모니터링을 사용해왔다. 그러나 DoH를 통한 암호화된 트래픽은 이러한 로컬 정책을 우회할 가능성이 있으며, 이는 네트워크 보안 정책의 유효성을 떨어뜨리고 악성 도메인에 대한 차단을 어렵게 만들 수 있다. 결과적으로, 보안과 프라이버시의 균형을 어떻게 맞출 것인지에 대한 논의가 필요해졌다.

DoH의 도입은 암호화를 통해 사용자 프라이버시를 강화하지만, 동시에 기존 네트워크 관리 및 보안 모델에 새로운 과제를 제기한다. 특히 네트워크 관리자가 DNS 트래픽을 모니터링하거나 특정 정책에 따라 필터링하는 것이 어려워진다.

기존 DNS는 일반적으로 평문 UDP 또는 TCP 53번 포트를 사용하기 때문에, 네트워크 경계에서 트래픽을 쉽게 식별하고 감시하거나 차단할 수 있었다. 예를 들어, 기업이나 교육기관은 내부 네트워크에서 악성 사이트나 업무 외 사이트에 대한 DNS 쿼리를 차단하는 정책을 적용하기 쉬웠다. 그러나 DoH는 모든 DNS 쿼리와 응답이 일반적인 HTTPS 트래픽(주로 443번 포트)과 섞여 암호화된 채로 전송된다. 이로 인해 네트워크 장비는 특정 패킷이 일반 웹 트래픽인지, 아니면 DNS 쿼리를 캡슐화한 것인지 구분할 수 없게 된다.

이로 인해 발생하는 주요 문제점은 다음과 같다.

이러한 변화는 기업 보안 정책 준수, 학교나 공공기관의 적절한 인터넷 사용 관리, 심지어 국가 차원의 악성코드 확산 방지나 불법 콘텐츠 차단 노력에도 영향을 미칠 수 있다. 일부 조직은 이를 우회하기 위해 허용된 DoH 리졸버 목록을 관리하거나, 네트워크 차원에서 알려진 공용 DoH 서버 주소를 차단하는 방법을 모색하고 있다. 그러나 이는 기술적 고양이와 쥐 게임으로 이어질 수 있으며, 궁극적으로는 네트워크 관리의 패러다임 변화를 요구한다.

DoH는 기존 DNS에 비해 암호화와 HTTPS 프로토콜 사용으로 인해 일정 수준의 성능 오버헤드가 발생합니다. 이 오버헤드는 주로 연결 설정 시간과 처리 자원 소모에서 기인합니다.

기존 DNS는 단순한 UDP 패킷을 사용하여 빠른 요청-응답이 가능했지만, DoH는 먼저 TCP 연결을 설정하고, 그 위에서 TLS 핸드셰이크를 완료해야 합니다. 이 과정에서 추가적인 왕복 시간(RTT)이 소요됩니다. 특히 첫 번째 쿼리 시 이 오버헤드가 두드러지며, 이후에는 지속 연결(HTTP/2의 멀티플렉싱 기능 등)을 통해 여러 쿼리를 효율적으로 처리하여 오버헤드를 상당 부분 완화할 수 있습니다. 그러나 연결 유지가 끊기면 다시 초기 설정 비용이 발생합니다.

또한, 암호화와 복호화 과정은 클라이언트와 리졸버 서버 양측에 추가적인 CPU 연산 부담을 줍니다. HTTP 계층의 처리와 더 큰 패킷 크기로 인한 네트워크 대역폭 사용 증가도 간과할 수 없는 요소입니다. 이러한 오버헤드는 고성능 장비에서는 미미할 수 있지만, 저사양 IoT 기기나 혼잡한 네트워크 환경에서는 상대적으로 더 큰 영향을 미칠 수 있습니다. 전반적으로 DoH는 보안과 프라이버시 향상이라는 대가로 일부 성능을 교환하는 트레이드오프 관계에 있습니다.

DoT(DNS over TLS)는 DNS 쿼리와 응답을 TLS(전송 계층 보안) 프로토콜을 통해 암호화하여 전송하는 보안 프로토콜이다. 이 기술은 기존의 평문 DNS 트래픽이 가진 도청, 변조, 중간자 공격 등의 취약점을 해결하기 위해 개발되었다. DoT는 표준 TCP 포트 853을 사용하여 전용 연결을 통해 암호화된 DNS 통신을 수행한다. 이는 HTTPS가 사용하는 포트 443과 유사하게, 특정 포트를 통해 암호화된 트래픽임을 명시적으로 식별할 수 있게 한다.

DoT의 동작 방식은 다음과 같다. 클라이언트는 DNS 리졸버와 표준 TLS 핸드셰이크를 수행하여 보안 채널을 수립한다. 이 핸드셰이크 과정에서 서버의 신원을 확인하고 암호화에 사용할 세션 키를 협상한다. 성공적으로 채널이 설정된 후, 모든 DNS 쿼리와 응답은 이 암호화된 TLS 터널 내에서 일반 DNS 프로토콜 메시지 형태로 교환된다. 이로 인해 네트워크 경로상의 제3자는 통신 내용을 확인하거나 변조할 수 없다.

DoT는 DoH(DNS over HTTPS)와 주요한 차이점을 가진다. 가장 두드러진 차이는 사용하는 프로토콜과 포트이다. DoT는 DNS 전용 포트(853)를 사용하는 반면, DoH는 웹 트래픽과 같은 포트(443)와 프로토콜(HTTP/2 또는 HTTP/3)을 사용한다. 이로 인해 DoT 트래픽은 네트워크 관리자가 식별하고 필요한 경우 별도의 정책을 적용하기가 상대적으로 용이하다. 또한 DoT는 애플리케이션 계층이 아닌 전송 계층에서 암호화를 제공하여, 기존 DNS 프로토콜 구조와 운영 모델을 더 잘 유지한다는 점에서 일부 관리자들에게 선호된다.

다음 표는 DoT와 DoH의 주요 차이점을 요약한다.

DoT는 Android 9 (파이) 이상 및 일부 라우터 펌웨어와 리눅스 배포판에 기본적으로 지원되며, Unbound나 Knot Resolver와 같은 오픈소스 리졸버를 통해 구현할 수 있다. 그러나 웹 브라우저에서는 DoH에 비해 직접적인 지원이 적은 편이다.

DoQ는 DNS 쿼리와 응답을 QUIC 전송 프로토콜 위에서 암호화하여 전송하는 표준이다. IETF에서 표준화 작업이 진행되었으며, DoH와 DoT에 이은 세 번째 주요 암호화된 DNS 프로토콜로 자리 잡았다. QUIC 프로토콜이 UDP를 기반으로 하여 TCP의 핸드셰이크 지연을 제거한 것처럼, DoQ도 연결 설정 지연을 최소화하면서 암호화와 데이터 무결성을 제공하는 것을 목표로 한다.

DoQ의 핵심 장점은 QUIC 프로토콜의 고유한 특성에서 비롯된다. 첫째, QUIC는 연결 설정 시 필수적인 TLS 암호화 핸드셰이크를 초기 연결 협상에 통합하여, DoT에서 필요한 별도의 TCP 및 TLS 핸드셰이크 단계를 생략한다. 이로 인해 첫 번째 DNS 쿼리의 지연 시간(레이턴시)이 크게 줄어든다. 둘째, 멀티플렉싱을 지원하여 단일 QUIC 연결 내에서 여러 DNS 쿼리를 병렬로 처리할 수 있으며, Head-of-Line 블로킹 문제를 피할 수 있다. 셋째, 연결 마이그레이션 기능을 통해 클라이언트의 네트워크가 변경되어도(예: Wi-Fi에서 셀룰러로 전환) 기존 DNS 쿼리 세션을 유지할 수 있다.

다음은 DoQ를 다른 암호화된 DNS 프로토콜과 비교한 표이다.

DoQ는 아직 DoH나 DoT만큼 광범위하게 배포되지는 않았지만, AdGuard Home이나 PowerDNS Recursor와 같은 일부 리졸버와 클라이언트에서 실험적 또는 프로덕션 지원을 시작했다. 표준화 과정이 완료됨에 따라, 낮은 지연 시간과 향상된 연결 복원력이 요구되는 모바일 환경 및 엣지 컴퓨팅에서의 적용이 기대된다.

DNS는 기본적으로 UDP 포트 53을 사용하여 동작한다. UDP는 연결 설정 없이 데이터를 전송하는 비연결형 프로토콜이므로, 핸드셰이크 과정이 필요 없어 속도가 빠르고 오버헤드가 적다는 장점이 있다. 대부분의 DNS 쿼리는 단일 요청과 응답으로 이루어지며, 이 작은 크기의 패킷은 UDP에 매우 적합하다. 그러나 응답 메시지 크기가 512바이트를 초과하거나 트랜잭션 ID 재사용 등의 이유로 TCP 포트 53을 사용하기도 한다. TCP는 신뢰성 있는 연결을 보장하지만, 연결 설정 및 해제에 따른 추가 시간이 소요된다.

기존 DNS의 가장 큰 문제점은 평문 통신이다. DNS 쿼리와 응답은 암호화되지 않은 채로 네트워크를 통해 전송된다. 이는 패킷 스니핑을 통해 사용자가 방문하려는 웹사이트의 도메인을 쉽게 확인할 수 있음을 의미한다. 또한, 중간자 공격을 통해 응답을 가로채거나 변조하여 사용자를 악성 사이트로 유도하는 DNS 스푸핑 공격에 취약하다.

다음 표는 기존 DNS의 주요 특성을 요약한 것이다.

이러한 보안 및 프라이버시 취약점은 DNSSEC으로 데이터 무결성 문제를 부분적으로 해결하려 했으나, 여전히 통신 내용의 기밀성은 보호되지 않았다. 기존 DNS 구조는 네트워크 관리자가 내부 트래픽을 모니터링하고 필터링하기는 용이하지만, 사용자의 질의 내용이 ISP를 포함한 경로 상의 모든 관찰자에게 노출된다는 근본적인 한계를 가지고 있었다. 이 한계가 DoH와 DoT 같은 암호화된 DNS 프로토콜이 등장하는 직접적인 배경이 되었다.

모질라 파이어폭스는 2018년에 Cloudflare를 기본 DoH 공급자로 설정하여 DoH를 기본적으로 활성화한 최초의 주요 웹 브라우저였다[4]. 이는 사용자의 DNS 트래픽을 암호화하여 ISP의 감시로부터 보호하려는 목적이었다. 사용자는 설정에서 DoH를 끄거나 다른 공급자로 변경할 수 있다.

구글 크롬은 2019년부터 실험적 기능으로 DoH 지원을 시작했으며, 점진적으로 확대해 나갔다. 초기에는 사용자가 플래그를 통해 명시적으로 활성화해야 했으나, 이후 자동 업그레이드를 통해 특정 조건을 만족하는 사용자에게 점진적으로 활성화하는 방식을 취했다. 크롬은 사용자의 운영체제 DNS 설정을 감지하여, 기존 DNS 서버가 DoH를 지원하면 동일한 공급자로 자동 전환하는 '자동 업그레이드' 방식을 사용하기도 한다.

마이크로소프트 엣지와 애플 사파리도 이후 DoH를 지원하기 시작했다. 엣지는 설정 내에서 사용자가 DoH 공급자를 선택할 수 있는 옵션을 제공한다. 사파리의 경우, macOS 및 iOS의 시스템 수준 네트워크 설정과 긴밀하게 연동되어 동작한다. 즉, 시스템 설정에서 DoH를 구성하면 사파리를 포함한 시스템의 모든 애플리케이션이 해당 설정을 사용한다.

이러한 브라우저들의 DoH 도입은 사용자 프라이버시 향상에 기여했지만, 기업 네트워크의 정책이나 국가별 규제와 충돌하는 경우도 발생했다. 따라서 대부분의 브라우저는 특정 조건(예: 부모al 감지, 기업 정책 존재)에서는 DoH를 자동으로 활성화하지 않는 예외 정책을 두고 있다.

운영체제 수준에서 DoH를 활성화하는 것은 시스템 전체의 DNS 트래픽을 암호화한다는 점에서 웹 브라우저 단위의 설정보다 포괄적이다. 주요 운영체제들은 점차 DoH 지원을 네이티브 기능으로 통합하고 있다. 예를 들어, 마이크로소프트 윈도우는 설정 앱 또는 그룹 정책을 통해 지정된 DoH 리졸버를 시스템 기본값으로 설정할 수 있다. 애플의 macOS와 iOS는 네트워크 설정에서 자동 또는 수동 DoH 구성을 지원하며, 리눅스 배포판의 경우 systemd-resolved와 같은 시스템 서비스를 통해 DoH를 설정할 수 있다.

네트워크 장비나 라우터에서 DoH를 구성하면 해당 네트워크에 연결된 모든 장치의 DNS 요청을 중앙에서 암호화할 수 있다. 이는 가정이나 소규모 사무실 네트워크에서 유용하다. 사용자는 OpenWrt 또는 DD-WRT와 같은 커스텀 펌웨어가 설치된 라우터에서 DoH 포워딩을 설정하거나, 기업용 네트워크 장비에서는 해당 벤더의 안내에 따라 DoH 리졸버를 지정한다. 또한, 파이어월이나 유니파이 게이트웨이와 같은 일부 네트워크 보안 장비도 DoH 업스트림 서버 설정 기능을 제공한다.

구체적인 설정 방법은 운영체제와 네트워크 환경에 따라 상이하다. 일반적으로 필요한 정보는 DoH 공급자의 URL (예: https://cloudflare-dns.com/dns-query)과 때로는 인증서 정보이다. 아래 표는 주요 운영체제의 DoH 설정 경로를 요약한 것이다.

기업 환경에서는 네트워크 보안 강화와 내부 정책 준수를 위해 DoH를 선택적으로 도입하는 사례가 나타난다. 일부 기업은 직원의 원격 근무 시 보안을 높이기 위해 회사 관리 VPN과 연계하여 DoH를 사용하도록 설정한다. 이를 통해 공용 와이파이 등 불안정한 네트워크에서도 DNS 쿼리가 암호화되어 회사 데이터 유출 위험을 줄일 수 있다. 반면, 기업 내에서는 모든 DNS 트래픽을 모니터링하고 필터링해야 하는 보안 정책과 충돌할 수 있어, DoH를 완전히 차단하거나 엄격하게 관리되는 내부 DoH 리졸버만 허용하는 경우도 흔하다.

일부 선도적인 인터넷 서비스 제공자(ISP)는 자체적인 DoH 서비스를 제공하기 시작했다. 이는 사용자에게 프라이버시 옵션을 제공하면서도 DNS 트래픽이 타사 업체로 유출되는 것을 방지하기 위한 전략이다. 예를 들어, 코모카스트(Comcast)는 2020년에 자사 Xfinity 인터넷 가입자를 위한 DoH 서비스를 출시했다[5]. 이를 통해 ISP는 기존의 평문 DNS 트래픽 감소에 대응하면서도 사용자 신뢰를 유지하려는 모습을 보인다.

국내외 통신사들의 도입 사례를 비교하면 다음과 같은 차이를 확인할 수 있다.

이러한 도입은 단순한 기술 변경을 넘어 사업 모델과 규제 환경의 변화를 반영한다. ISP의 경우, DoH의 광범위한 사용은 트래픽 분석과 데이터 기반 맞춤 광고 사업에 영향을 미칠 수 있다. 따라서 일부 ISP는 DoH를 경계하는 입장을 보이기도 하지만, 사용자 요구와 경쟁 압력에 따라 점진적으로 서비스를 수용하는 양상을 보인다.

DoH의 도입은 사용자 프라이버시 강화라는 명백한 이점에도 불구하고, 기존 네트워크 관리 및 보안 모델과 충돌하며 논쟁을 불러일으켰다. 핵심 논점은 개인의 통신 비밀을 보호하는 것과, 조직이나 국가가 네트워크를 감시하고 위협을 차단할 수 있는 능력을 유지하는 것 사이의 균형에 있다. 보안 담당자들은 DoH가 기업 방화벽, 안티바이러스 소프트웨어, 침입 탐지 시스템(IDS) 등이 악성 도메인을 탐지하고 차단하는 데 의존해 온 기존의 DNS 기반 필터링을 무력화할 수 있다고 지적한다. 이로 인해 내부 네트워크에서 멀웨어 감염이나 데이터 유출 사고가 발생할 경우, 조사와 대응이 어려워질 수 있다.

이 논쟁은 특히 인터넷 서비스 제공자(ISP)와 일부 정부 기관의 입장에서 두드러진다. ISP들은 전통적으로 사용자의 DNS 쿼리를 처리해 왔으나, DoH는 이러한 쿼리를 클라우드플레어나 구글과 같은 제3의 암호화된 리졸버로 우회시킨다. 이는 ISP가 네트워크 상태를 진단하거나, 불법 콘텐츠 접근 차단과 같은 법적 의무를 이행하는 데 장애물이 될 수 있다. 일부 국가에서는 DoH가 국가 차원의 인터넷 검열을 우회하는 수단으로 사용될 수 있다는 점을 우려하며, 해당 기술의 사용을 제한하거나 규제하려는 움직임을 보이기도 한다.

반면, DoH 지지자들은 이러한 "보안" 논리가 실제로는 대규모 감시와 통제를 정당화하는 데 악용될 수 있다고 반박한다. 그들은 암호화되지 않은 DNS가 사용자의 방문 기록을 ISP나 공공 와이파이 제공자 등이 쉽게 수집할 수 있게 하여, 심각한 프라이버시 침해와 중간자 공격(MitM)의 위험을 초래한다고 주장한다. DoH는 이러한 기본적인 취약점을 해결하는 필수적인 보안 업그레이드라는 입장이다. 논쟁의 해결을 위해, 기업 환경에서는 관리되는 DoH 설정을 도입하거나, 내부 정책을 통해 신뢰할 수 있는 리졸버를 지정하는 등의 절충안이 모색되고 있다.

인터넷 서비스 제공자(ISP)는 전통적으로 DNS 쿼리 처리와 관련된 네트워크 인프라 및 데이터에 대한 통제력을 유지해왔다. DoH의 등장은 이 통제력을 약화시킬 수 있어 많은 ISP가 부정적인 입장을 보인다. ISP는 DoH가 네트워크 내 불법 콘텐츠 차단, 악성 트래픽 모니터링, 자녀 보호 필터링, 지역별 캐싱을 통한 서비스 최적화 등 기존에 수행하던 관리 업무를 어렵게 만들거나 불가능하게 한다고 주장한다[7]. 또한, 사용자의 DNS 쿼리가 제3의 외부 DoH 공급자(예: Cloudflare, Google)로 집중되면 ISP의 트래픽 분석 및 부가가치 서비스 개발 기회가 줄어든다는 경제적 우려도 존재한다.

일부 국가의 정부 및 규제 기관은 DoH가 국가 차원의 인터넷 검열 및 감시 체계에 도전할 수 있다고 본다. DNS 차단은 불법 사이트나 정보 접근을 통제하는 일반적인 수단인데, DoH를 통하면 사용자가 이러한 차단을 쉽게 우회할 수 있기 때문이다. 이에 따라 중화인민공화국과 같은 국가에서는 DoH 사용을 제한하거나 차단하는 정책을 시행하기도 했다. 반면, 유럽 연합의 GDPR(일반 개인정보 보호 규정)과 같은 강력한 프라이버시 보호 법규 하에서는 DoH가 사용자 데이터 보호를 강화하는 기술로 평가받는 양면적인 입장이 존재한다.

이러한 논란 속에서 일부 ISP와 정부는 DoH의 무분별한 확산을 경계하면서도 기술의 필연성을 인정하고 대안을 모색한다. 일부 ISP는 자체적인 신뢰할 수 있는 DoH 서비스를 제공하거나, 기업 네트워크에서는 DoH를 비활성화할 수 있도록 하는 정책을 옹호한다. 규제 기관들은 사용자 프라이버시 보호와 합법적인 네트워크 관리 및 공공 안전 목적 사이의 균형을 찾기 위한 지침 마련에 고심하고 있다.

DoH(DNS over HTTPS)의 등장과 확산은 국제적인 표준화 기구와 각국 정부, 규제 기관의 관심을 집중시켰다. 핵심 논점은 인터넷의 개방성, 사용자 프라이버시, 국가 안보 및 네트워크 관리 권한 사이의 균형을 어떻게 맞출 것인가이다.

표준화 측면에서 DoH는 2018년 10월에 IETF(국제 인터넷 표준화 기구)에 의해 RFC 8484로 공식 표준화되었다[8]. 이 표준은 DoH의 프로토콜 메시지 형식, HTTPS를 이용한 전송 방법, JSON 형식의 응답 등 기술적 세부사항을 정의한다. IETF의 작업은 기술적 완성도를 높이는 동시에, 암호화를 통한 보안과 프라이버시 강화라는 인터넷 설계 원칙을 반영한 것이다. 이후 DoT(DNS over TLS) (RFC 7858) 및 DoQ(DNS over QUIC) (RFC 9250)와 같은 대안적 암호화 DNS 프로토콜도 표준으로 제정되어 사용자와 운영자에게 선택지를 제공한다.

규제와 정책적 움직임은 국가별로 상이한 입장을 보인다. 유럽 연합은 GDPR(일반 개인정보 보호 규정)과 같은 강력한 프라이버시 보호 법제 하에서 DoH를 사용자 권리 보호에 기여할 수 있는 기술로 바라보는 경향이 있다. 반면, 일부 국가에서는 DoH가 기존의 DNS 필터링 및 감시 체계를 무력화할 수 있다는 점을 우려한다. 예를 들어, 영국의 정보통신 규제 기관 Ofcom은 DoH가 불법 콘텐츠 차단 효율성을 저해할 수 있다고 지적한 바 있다. 중국과 러시아 등에서는 국가적 인터넷 검열 체계와의 충돌로 인해 DoH 트래픽을 차단하거나 제한하는 조치를 취하고 있다.

미래 규제 동향은 "암호화의 보편화"라는 기술 흐름과 국가별 "디지털 주권" 수호 정책 사이의 긴장 관계 속에서 형성될 것이다. ICANN(국제인터넷주소관리기구)과 같은 글로벌 거버넌스 기구들도 암호화된 DNS가 DNS 루트 서버 시스템과 도메인 네임 관리에 미칠 장기적 영향을 평가하고 있다. 결국, 기술 표준과 법적 규제는 사용자 보호, 네트워크 안정성, 공공 정책 목표라는 다양한 가치를 조정하는 과정에서 계속 진화할 것으로 예상된다.